home *** CD-ROM | disk | FTP | other *** search
/ Experimental BBS Explossion 3 / Experimental BBS Explossion III.iso / gus / digestv5.zip / V5N24M.TXT < prev    next >
Text File  |  1994-02-27  |  10KB  |  242 lines
  1. Apparently-To: john.smith@gravis.com
  2.  
  3.  
  4. GUS Musician's Digest       Sat, 26 Feb 94  4:14 erv     Volume 5: Issue  24  
  5.  
  6. Today's Topics:
  7.          DIGEST ADMIN:  *** READ ME!!! VERY IMPORTANT!!! ***
  8.                             Dropped notes
  9.                      GUS Musician's Digest V5 #23
  10.                       Organizing Custom Patches
  11.                           Patchmaker Heavy??
  12.  
  13. Standard Info:
  14.     - Meta-info about the GUS can be found at the end of the Digest.
  15.     - Before you ask a question, please READ THE FAQ.
  16.  
  17. ----------------------------------------------------------------------
  18.  
  19. Date: Fri, 25 Feb 1994 16:20:36 -0700 (MST)
  20. From: Dave DeBry <ddebry@dsd.es.com>
  21. Subject: DIGEST ADMIN:  *** READ ME!!! VERY IMPORTANT!!! ***
  22.  
  23.     You may have noticed that today's Digests came from a
  24. different site, namely mail.orst.edu.  This is a permanent change.
  25. Thanks to Kean Stump for providing a site for the move.  Please update
  26. your mail aliases to reflect the following new addresses:
  27.  
  28. GUS Daily Digest:        gus-general-request@mail.orst.edu
  29.     Purpose:        General Gravis Ultrasound topics.
  30.     To post:        gus-general@mail.orst.edu
  31.     To talk to a human:    gus-general-owner@mail.orst.edu
  32.  
  33. GUS Musician's Digest:        gus-music-request@mail.orst.edu
  34.     Purpose:        For Gravis Ultrasound musicians.
  35.     To post:        gus-music@mail.orst.edu
  36.     To talk to a human:    gus-music-owner@mail.orst.edu
  37.  
  38. GUS Programmer's Digest:    gus-sdk-request@mail.orst.edu
  39.     Purpose:        For Gravis Ultrasound programmers.
  40.     To post:        gus-sdk@mail.orst.edu
  41.     To talk to a human:    gus-general-sdk@mail.orst.edu
  42.  
  43.  -------------------------------------------------------------------------
  44.  
  45. *** GUS WARNING!!! ***
  46.     Neither the GUS lists or the list operator are owned or
  47.     operated by Gravis.  Please don't mail your complaints
  48.     concerning the Ultrasound to the list owner.  There are 
  49.     Gravis employees on the lists, so post your problems there.
  50.  
  51.  -------------------------------------------------------------------------
  52.  
  53.  
  54.  
  55. -- 
  56. Dave  ddebry@ debry@   \ "Hey Rocky!  Watch me pull a rabbit out of my hat."
  57. DeBry dsd.    peruvian. |"Aw, that trick never works." 
  58.       es.     cs.utah.  |"Shut up, you damn squirrel!  I'm sick and tired
  59.       com     edu      /  of your !@%$%& pessimistic attitude!"
  60.  
  61. ------------------------------
  62.  
  63. Date: Fri, 25 Feb 1994 11:22:09 -0500 (EST)
  64. From: Phat H Tran <ptran@sciborg.uwaterloo.ca>
  65. Subject: Dropped notes
  66.  
  67. > Date: Thu, 24 Feb 1994 17:11:36 PST
  68. > From: Steve Peddle <speddle@wpg.paramax.com>
  69. > Subject: dropped notes
  70. > 
  71. > In a previous digest phat said that the new windows drivers are better ie 
  72. > drop less notes?  I thought that any dropped midi event would be a 
  73. > serious problem.  For example notes could get stuck on.  Or does better 
  74. > mean you can run faster without dropping any notes?
  75.  
  76. Actually, events don't appear to be dropped, just the occasional notes.
  77. So there's never a stuck note or a missed program change.
  78.  
  79. BTW, Forte are doing a complete overhaul of the Windows driver (they
  80. changed programmers, I believe) and, hopefully, will squish bugs such 
  81. as this one in the process.  Don't expect the new drivers to be 
  82. released too soon, though.
  83.  
  84. Phat.
  85.  
  86. ------------------------------
  87.  
  88. Date: Fri, 25 Feb 1994 10:25:33 -0800
  89. From: chrisw@popserver.stanford.edu (Chris Wilkins)
  90. Subject: Re: GUS Musician's Digest V5 #23
  91.  
  92. >From: tclee@iss.nus.sg (Lee Teck Chee)
  93. >
  94. >I have compiled a preliminary list of patches that are available on epas 
  95. and its
  96. >mirrors. I am arranging them, tentatively, by patch name, archive 
  97. containing this
  98. >patch, patch information (ie 8/16-bit, sample rate, number of multisamples),
  99. >suggested replacement (if any), and patch category.
  100.  
  101. You are doing a great public service! The question is, how will this list be 
  102. updated? Are you volunteering to have all people submitting new patches mail 
  103. a description to you? (Fine by me).
  104.  
  105. You've left out a really important one in the properties though: size! 
  106. Particularly for modem downloaders and those with < 1M Gusses. Also, you 
  107. should probably have looped / unlooped as well as a property. 
  108.  
  109. Also, it would be useful to have cross references for patches which have 
  110. something in common. eg. patches which are smaller versions of other 
  111. patches. In a similar vein, it would be useful to have something on the 
  112. origins of the patches. That is, if they are based on some public samples, 
  113. then they should probably say the file so that people know if it's new 
  114. waveform material or just new loops and envelopes. (eg. the bosendorfer 
  115. piano series). Same thing for samples from synth equipment (if people want 
  116. to own up!). All patches based on the same waveform data should really be 
  117. grouped together in your list.
  118.  
  119. >I would like to seek views on how best to define the different categories. 
  120. Currently
  121. >I am basing them on GM categories, but this may be quite limiting. Phat has
  122. >suggested that we categorize based on electronic or acoustic and then 
  123. subdividing
  124. >those. Any suggestions?
  125.  
  126. The tricky thing is going to be defining synthy patches I guess, put the 
  127. usual sort of bass / lead / pad / FX sort of classification would probably 
  128. be O.K. 
  129.  
  130. Chris.
  131.  
  132. ------------------------------
  133.  
  134. Date: Fri, 25 Feb 94 14:20 MET
  135. From: hst@mh.nl (Klaas Hemstra)
  136. Subject: Re: Organizing Custom Patches
  137.  
  138. In the previous digest Lee Teck Chee (tclee@iss.nus.sg) sought for
  139. views on how to organize custom patches.
  140.  
  141. First i would like to say that i think the discussion should really be
  142. about how we can use all these custom patches in a user-friendly
  143. manner. More to the point: How can we program the GUS windows driver
  144. to use the patches from a Standard MIDI file, together with normal
  145. patches. I want to be able to play a MIDI files with a normal windows
  146. application. If one builds such an application (a midi player ?) then
  147. of course you come to the question: "How do i put the right
  148. information in the MIDI file". 
  149.  
  150. To address other patches together with normal GM patches you can:
  151. - Use the bank controler message. But how goes the driver know what
  152.   patch should be loaded, and how will you know what patch-bank the
  153.   MIDI-file was written for ?
  154. - You can define a SYSEX message that specifies the Patch-NAME for a
  155.   certain patch-number. The midi-player should filter the information
  156.   and should cause that patch to be loaded in stead of the normal one
  157.   for that number.
  158. - A combination of the two above.
  159.  
  160. I beleive the SYSEX message way is the best. In the case of the GUS,
  161. there will be many patches around, now and in the future. For many
  162. patches (like the TR707 drum set) it will not be likely that they will
  163. be supplied with each MIDI file that uses them. If we define a
  164. patch-bank for the patches that are available NOW it will be out of
  165. date tomorrow. Therefore the patch used in the MIDI file must be linked
  166. to the real patch on disk somehowe, and what is better then in the
  167. MIDI-file itself.
  168.  
  169. The SYSEX message should define one or more names, in a specific
  170. order, which should be tried in that order. If you also use a patch
  171. number that gives a suitable replacement in case the SYSEX message is
  172. not processed correctly (e.g. the custom patch is NOT found). You have
  173. all the fallback possibilities that are needed.
  174.  
  175. If you still think that it is necessary to define a patch-bank then
  176. here's my view on that:
  177.  
  178. My opinion is that you should place patches that simulate the same
  179. instrument in another bank, with the same patch number.
  180. That is the same way that Roland does it in the GS standard.
  181. So if you have a other Trumpet patch, it will be in bank 1 (not bank
  182. 0) but with the same patch number (57 wasn't it).
  183. It's a logical way to do it, if it goes wrong with banks you still
  184. have a fairly decent sounding MIDI song.
  185.  
  186. But what to do with patch-sounds that are not in the current GM set ?
  187. Well, i can think of two ways to do that.
  188.  
  189. You could allocate a higher bank for that (say bank 8) and put all
  190. those patches in there. That bank should be devided in categories too
  191. like GM, but most likely with other (less specific?) categories.
  192.  
  193. You can also put them in higher banks within the current GM
  194. categories. So if you have very specific guitar patch not resembling
  195. any of the other guitars you but it at patch 25 of bank 8.
  196.  
  197. Klaas
  198.  
  199. ------------------------------
  200.  
  201. Date: Fri, 25 Feb 1994 21:18:16 -0800 (PST)
  202. From: jtcapps@netcom.com (John T. Capps)
  203. Subject: Patchmaker Heavy??
  204.  
  205.         Well, nobody has asked this question yet, so I'll bite.
  206. In the announcement for the 16-bit daughtercard posted here a couple of
  207. days ago, it mentioned (among the other software titles) Patchmaker...NOT
  208. Lite, just Patchmaker.  Is this the much awaited upgrade?  Will it only
  209. be available with the daughtercard?  Am I the only one stewing in
  210. ignorance? :-)
  211.         Any info will be appreciated!
  212.  
  213. John
  214.  
  215. ------------------------------
  216.  
  217. End of GUS Musician's Digest V5 #24
  218. ***********************************
  219.  
  220. To post to tomorrow's digest:                        <gus-music@mail.orst.edu>
  221. To (un)subscribe or get help:                <gus-music-request@mail.orst.edu>
  222. To contact a human (last resort):              <gus-music-owner@mail.orst.edu>
  223.  
  224. FTP Sites              Archive                       Directories
  225. ---------              -------                       -----------
  226. Main N.American Site:  archive.orst.edu              pub/packages/gravis
  227.                        wuarchive.wustl.edu           systems/ibmpc/ultrasound
  228. Main Asian Site:       nctuccca.edu.tw               PC/ultrasound
  229. European Callers ONLY: theoris.rz.uni-konstanz.de    pub/sound/gus
  230. Submissions:           archive.epas.utoronto.ca      pub/pc/ultrasound/submit
  231. Newly Validated Files: archive.epas.utoronto.ca      pub/pc/ultrasound
  232. Mirrors:               garbo.uwasa.fi                mirror/ultrasound
  233.  
  234. MailServer For Archive Access: Email to <mail-server@nike.rz.uni-konstanz.de>
  235.  
  236. Hints:
  237.       - Get the FAQ from the FTP sites or the request server.
  238.       - Mail to <gus-music-request@mail.orst.edu> for info about other
  239.     GUS related mailing lists (general use, programmers, etc.).
  240.  
  241.  
  242.